home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000136_news@newsmaster….columbia.edu _Tue May 26 15:17:46 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id PAA27568
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 26 May 1998 15:17:44 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id PAA18275
  7.     for kermit.misc@watsun; Tue, 26 May 1998 15:17:43 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!cpk-news-hub1.bbnplanet.com!wtn-news-feed2.bbnplanet.com!news.bbnplanet.com!netnews.jhuapl.edu!usenet
  9. From: Skip Collins <collibf1@jhuapl.edu>
  10. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  11. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  12. Date: 26 May 1998 15:11:21 -0400
  13. Organization: Johns Hopkins University Applied Physics Lab, Laurel, MD, USA
  14. Lines: 38
  15. Sender: collibf1@COLLIBF1
  16. Message-ID: <wk67is4zl2.fsf@jhuapl.edu>
  17. References: <35646665.EBB3868B@theriver.com> <wk67iy1b8j.fsf@jhuapl.edu> <6k4ef6$g6p$1@apakabar.cc.columbia.edu> <wk4syi58y0.fsf@jhuapl.edu> <6kc4vm$ssl$1@apakabar.cc.columbia.edu>
  18. NNTP-Posting-Host: collibf1-2.jhuapl.edu
  19. X-Newsreader: Gnus v5.5/Emacs 20.2
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:8799 comp.sys.hp48:81471
  21.  
  22. fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  23.  
  24. > In article <wk4syi58y0.fsf@jhuapl.edu>,
  25. > Skip Collins  <collibf1@jhuapl.edu> wrote:
  26. > : What command should I issue to mimic the K95 default?
  27. >
  28. >   SET CONTROL UNPREFIX ALL
  29. >   SET CONTROL PREFIX 0 1 13 17 19 129 141 145 147
  30.  
  31. I find that setting _any_ unprefixed control characters, in the low or
  32. high range, causes problems. A transfer just stops and retries occur
  33. until the limit is exceeded. This is one area where a re-implemented
  34. hp48 kermit could easily improve performance.
  35.  
  36. > : > There is no prohibition in the protocol definition against sending bare
  37. > : > control characters,
  38. > :
  39. > : This seems to contradict "Kermit: A File Transfer Protocol", 1987 ed.,
  40. > : which states on page 248, under the heading Encoding Summary: "Prefix
  41. > : encoding for control characters is mandatory."
  42. > :
  43. > No good deed goes unpunished.
  44.  
  45. It seems that the programmers at hp took you at your word. While there
  46. were plenty of unfortunate choices made in the implementation of the
  47. protocol on the hp48, this behavior is at least defensible. If a
  48. control character comes along, it is pretty good indicator of a bad
  49. packet, assuming control characters are not allowed. Which is not a
  50. bad assumption, given the wording of the protocol specification. The
  51. hp48 team was just being extra careful about error checking :).
  52.  
  53. I think I remember reading somewhere that there was some sort of
  54. problem between the kermit project and the hp48 designers. Is this
  55. true? If so, it's a shame that there could not have been closer
  56. cooperation between the two parties. These programming problems should
  57. have been fixed years ago.
  58.  
  59. Skip